.. _rfc3261: RFC3261: SIP: Session Initiation Protocol ######################################### * Obsoletes: ``rfc2543`` * Category: Standards Track * June 2002 * From: dynamicsoft, Columbia U., Ericsson, WorldCom, Neustar, ICIR, AT&T Abstract ======== * This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. * These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. * SIP invitations used to create sessions carry session descriptions that allow participants to agree on a set of compatible media types. * SIP makes use of elements called proxy servers to help route requests to the user's current location, authenticate and authorize users for services, implement provider call-routing policies, and provide features to users. * SIP also provides a registration function that allows users to upload their current locations for use by proxy servers. * SIP runs on top of several different transport protocols. 1 Introduction ============== * There are many applications of the Internet that require the creation and management of a session, where a session is considered an exchange of data between an association of participants. * The implementation of these applications is complicated by the practices of participants: users may move between endpoints, they may be addressable by multiple names, and they may communicate in several different media - sometimes simultaneously. * Numerous protocols have been authored that carry various forms of real-time multimedia session data such as voice, video, or text messages. * The Session Initiation Protocol (SIP) works in concert with these protocols by enabling Internet endpoints (called user agents) to discover one another and to agree on a characterization of a session they would like to share. * For locating prospective session participants, and for other functions, SIP enables the creation of an infrastructure of network hosts (called proxy servers) to which user agents can send registrations, invitations to sessions, and other requests. * SIP is an agile, general-purpose tool for creating, modifying, and terminating sessions that works independently of underlying transport protocols and without dependency on the type of session that is being established. 2 Overview of SIP Functionality =============================== * SIP can also invite participants to already existing sessions, such as multicast conferences. Media can be added to (and removed from) an existing session. SIP supports five facets of establishing and terminating multimedia communications:: 1. User location: determination of the end system to be used for communication; 2. User availability: determination of the willingness of the called party to engage in communications; 3. User capabilities: determination of the media and media parameters to be used; 4. Session setup: "ringing", establishment of session parameters at both called and calling party; 5. Session management: including transfer and termination of sessions, modifying session parameters, and invoking services. * SIP is not a vertically integrated communications system. * SIP is rather a component that can be used with other IETF protocols to build a complete multimedia architecture. * Typically, these architectures will include protocols such as the Real-time Transport Protocol (RTP) (RFC 1889 [28]) for transporting real-time data and providing QoS feedback, the Real-Time streaming protocol (RTSP) (RFC 2326 [29]) for controlling delivery of streaming media, the Media Gateway Control Protocol (MEGACO) (RFC 3015 [30]) for controlling gateways to the Public Switched Telephone Network (PSTN), and the Session Description Protocol (SDP) (RFC 2327 [1]) for describing multimedia sessions. 4 Overview of Operation ======================= .. note:: This section introduces the basic operations of SIP using simple examples. This section is tutorial in nature and does not contain any normative statements. * The first example shows the basic functions of SIP: location of an end point, signal of a desire to communicate, negotiation of session parameters to establish the session, and teardown of the session once established. * In this example, Alice uses a SIP application on her PC (referred to as a softphone) to call Bob on his SIP phone over the Internet. * Also shown are two SIP proxy servers that act on behalf of Alice and Bob to facilitate the session establishment. Figure 1: SIP session setup example with SIP trapezoid:: atlanta.com . . . biloxi.com . proxy proxy . . . Alice's . . . . . . . . . . . . . . . . . . . . Bob's softphone SIP Phone | | | | | INVITE F1 | | | |--------------->| INVITE F2 | | | 100 Trying F3 |--------------->| INVITE F4 | |<---------------| 100 Trying F5 |--------------->| | |<-------------- | 180 Ringing F6 | | | 180 Ringing F7 |<---------------| | 180 Ringing F8 |<---------------| 200 OK F9 | |<---------------| 200 OK F10 |<---------------| | 200 OK F11 |<---------------| | |<---------------| | | | ACK F12 | |------------------------------------------------->| | Media Session | |<================================================>| | BYE F13 | |<-------------------------------------------------| | 200 OK F14 | |------------------------------------------------->| | | URI:: sip:bob@biloxi.com sips:bob@biloxi.com * SIP is based on an HTTP-like request/response transaction model. * Each transaction consists of a request that invokes a particular method, or function, on the server and at least one response. The INVITE (message F1 in Figure 1) might look like this:: INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds Max-Forwards: 70 To: Bob From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710@pc33.atlanta.com CSeq: 314159 INVITE Contact: Content-Type: application/sdp Content-Length: 142 (Alice's SDP not shown) * ``Via`` contains the address (pc33.atlanta.com) at which Alice is expecting to receive responses to this request. It also contains a branch parameter that identifies this transaction. * ``Max-Forwards`` serves to limit the number of hops a request can make on the way to its destination. It consists of an integer that is decremented by one at each hop. * ``Call-ID`` contains a globally unique identifier for this call, generated by the combination of a random string and the softphone's host name or IP address. The combination of the To tag, From tag, and Call-ID completely defines a peer-to-peer SIP relationship between Alice and Bob and is referred to as a dialog. * ``CSeq`` or Command Sequence contains an integer and a method name. The CSeq number is incremented for each new request within a dialog and is a traditional sequence number. * The details of the session, such as the type of media, codec, or sampling rate, are not described using SIP. * [F2、F3步说明]The atlanta.com SIP server is a type of SIP server known as a proxy server. A proxy server receives SIP requests and forwards them on behalf of the requestor. In this example, the proxy server receives the INVITE request and sends a 100 (Trying) response back to Alice's softphone. The 100 (Trying) response indicates that the INVITE has been received and that the proxy is working on her behalf to route the INVITE to the destination. * [F6步说明]Bob's SIP phone receives the INVITE and alerts Bob to the incoming call from Alice so that Bob can decide whether to answer the call, that is, Bob's phone rings. Bob's SIP phone indicates this in a 180 (Ringing) response, which is routed back through the two proxies in the reverse direction. When Alice's softphone receives the 180 (Ringing) response, it passes this information to Alice, perhaps using an audio ringback tone or by displaying a message on Alice's screen. * [F9步说明]When Bob picks up the handset, his SIP phone sends a 200 (OK) response to indicate that the call has been answered. The 200 (OK) contains a message body with the SDP media description of the type of session that Bob is willing to establish with Alice. If Bob did not wish to answer the call or was busy on another call, an error response would have been sent instead of the 200 (OK), which would have resulted in no media session being established. The 200 (OK) (message F9 in Figure 1) might look like this as Bob sends it out:: SIP/2.0 200 OK Via: SIP/2.0/UDP server10.biloxi.com ;branch=z9hG4bKnashds8;received=192.0.2.3 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com ;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2 Via: SIP/2.0/UDP pc33.atlanta.com ;branch=z9hG4bK776asdhds ;received=192.0.2.1 To: Bob ;tag=a6c85cf From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710@pc33.atlanta.com CSeq: 314159 INVITE Contact: Content-Type: application/sdp Content-Length: 131 (Bob's SDP not shown) * There are three Via header field values - one added by Alice's SIP phone, one added by the atlanta.com proxy, and one added by the biloxi.com proxy. 5 Structure of the Protocol =========================== * SIP is structured as a layered protocol, which means that its behavior is described in terms of a set of fairly independent processing stages with only a loose coupling between each stage. * Not every element specified by the protocol contains every layer. * Furthermore, the elements specified by SIP are logical elements, not physical ones. layers of SIP:: 1. The lowest layer of SIP is its `syntax and encoding`. 2. The second layer is the `transport layer`. 3. The third layer is the `transaction layer`. 4. The toppest layer is called the `transaction user (TU)`. transaction layer:: Transactions are a fundamental component of SIP. A transaction is a request sent by a client transaction to a server transaction, along with all responses to that request sent from the server transaction back to the client. The transaction layer handles application-layer retransmissions, matching of responses to requests, and application-layer timeouts. Any task that a user agent client (UAC) accomplishes takes place using a series of transactions. User agents contain a transaction layer, as do stateful proxies. Stateless proxies do not contain a transaction layer. The transaction layer has a client component and a server component, each of which are represented by a finite state machine that is constructed to process a particular request. 6 Definitions ============= * Address-of-Record(AOR): is a SIP or SIPS URI that points to a domain with a location service that can map the URI to another URI where the user might be available. * Back-to-Back User Agent (B2BUA): is a logical entity that receives a request and processes it as a user agent server (UAS). .. todo:: 待后续完善 7 SIP Messages ============== * A SIP message is either a request from a client to a server, or a response from a server to a client. :: generic-message = start-line *message-header CRLF [ message-body ] start-line = Request-Line / Status-Line * Except some character set and syntax specifics, much of SIP's message and header field syntax is identical to HTTP/1.1. * However, SIP is not an extension of HTTP. 7.1 Requests ------------ :: Request-Line = Method SP Request-URI SP SIP-Version CRLF 参数: Method: REGISTER for registering contact information, INVITE, ACK, and CANCEL for setting up sessions, BYE for terminating sessions, OPTIONS for querying servers about their capabilities. 7.2 Responses ------------- :: Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF SIP/2.0 allows six values for the first digit:: 1xx: Provisional request received, continuing to process the request; 2xx: Success the action was successfully received, understood, and accepted; 3xx: Redirection further action needs to be taken in order to complete the request; 4xx: Client Error the request contains bad syntax or cannot be fulfilled at this server; 5xx: Server Error the server failed to fulfill an apparently valid request; 6xx: Global Failure the request cannot be fulfilled at any server. 7.3 Header Fields ----------------- :: header = "header-name" HCOLON header-value *(COMMA header-value) 7.4 Bodies ---------- * The Internet media type of the message body MUST be given by the Content-Type header field. * If the body has undergone any encoding such as compression, then this MUST be indicated by the Content- Encoding header field; otherwise, Content-Encoding MUST be omitted. * The body length in bytes is provided by the Content-Length header field. 7.5 Framing SIP Messages ------------------------ * Unlike HTTP, SIP implementations can use UDP or other unreliable datagram protocols. * Each such datagram carries one request or response. 8 General User Agent Behavior ============================= * A user agent represents an end system. It contains a user agent client (UAC), which generates requests, and a user agent server (UAS), which responds to them. * UAC and UAS procedures depend strongly on two factors. First, based on whether the request or response is inside or outside of a dialog, and second, based on the method of a request. 8.1 UAC Behavior ---------------- * Requests sent outside of a dialog include an INVITE to establish a session (Section 13) and an OPTIONS to query for capabilities (Section 11). 8.1.1 Generating the Request ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ A valid SIP request formulated by a UAC MUST contain the following header fields:: 1. To, 2. From, 3. CSeq, 4. Call-ID, 5. Max-Forwards, 6. Via 8.1.2 Sending the Request ^^^^^^^^^^^^^^^^^^^^^^^^^ * The destination for the request is then computed. * Unless there is local policy specifying otherwise, the destination MUST be determined by applying the DNS procedures described in [4] as follows. 8.1.3 Processing Responses ^^^^^^^^^^^^^^^^^^^^^^^^^^ * Responses are first processed by the transport layer and then passed up to the transaction layer. * The transaction layer performs its processing and then passes the response up to the TU. * The majority of response processing in the TU is method specific. * However, there are some general behaviors independent of the method. 8.1.3.1 Transaction Layer Errors """""""""""""""""""""""""""""""" * In some cases, the response returned by the transaction layer will not be a SIP message, but rather a transaction layer error. * When a timeout error is received from the transaction layer, it MUST be treated as if a 408 (Request Timeout) status code has been received. * If a fatal transport error is reported by the transport layer (generally, due to fatal ICMP errors in UDP or connection failures in TCP), the condition MUST be treated as a 503 (Service Unavailable) status code. 8.1.3.2 Unrecognized Responses """""""""""""""""""""""""""""" * A UAC MUST treat any final response it does not recognize as being equivalent to the x00 response code of that class, and MUST be able to process the x00 response code for all classes. * For example, if a UAC receives an unrecognized response code of 431, it can safely assume that there was something wrong with its request and treat the response as if it had received a 400 (Bad Request) response code. 8.1.3.3 Vias """""""""""" * If more than one Via header field value is present in a response, the UAC SHOULD discard the message. * The presence of additional Via header field values that precede the originator of the request suggests that the message was misrouted or possibly corrupted. 8.2 UAS Behavior ---------------- * UASs SHOULD process the requests in the order of the steps that follow in this section (that is, starting with authentication, then inspecting the method, the header fields, and so on throughout the remainder of this section). 8.2.1 Method Inspection ^^^^^^^^^^^^^^^^^^^^^^^ * Once a request is authenticated (or authentication is skipped), the UAS MUST inspect the method of the request. * If the UAS recognizes but does not support the method of a request, it MUST generate a 405 (Method Not Allowed) response. * If the method is one supported by the server, processing continues. 8.2.2 Header Inspection ^^^^^^^^^^^^^^^^^^^^^^^ * If a UAS does not understand a header field in a request, the server MUST ignore that header field and continue processing the message 8.2.2.1 To and Request-URI """""""""""""""""""""""""" * If the Request-URI uses a scheme not supported by the UAS, it SHOULD reject the request with a 416 (Unsupported URI Scheme) response. * If the Request-URI does not identify an address that the UAS is willing to accept requests for, it SHOULD reject the request with a 404 (Not Found) response. 8.2.2.2 Merged Requests """"""""""""""""""""""" * The same request has arrived at the UAS more than once, following different paths, most likely due to forking. * The UAS processes the first such request received and responds with a 482 (Loop Detected) to the rest of them. 8.2.2.3 Require """"""""""""""" * If a UAS does not understand an option-tag listed in a Require header field, it MUST respond by generating a response with status code 420 (Bad Extension). Example:: UAC->UAS: INVITE sip:watson@bell-telephone.com SIP/2.0 Require: 100rel UAS->UAC: SIP/2.0 420 Bad Extension Unsupported: 100rel 8.2.3 Content Processing ^^^^^^^^^^^^^^^^^^^^^^^^ * If there are any bodies whose type (indicated by the Content-Type), language (indicated by the Content-Language) or encoding (indicated by the Content-Encoding) are not understood, and that body part is not optional (as indicated by the Content-Disposition header field), the UAS MUST reject the request with a 415 (Unsupported Media Type) response. 8.2.4 Applying Extensions ^^^^^^^^^^^^^^^^^^^^^^^^^ * If the desired extension is not supported, the server SHOULD rely only on baseline SIP and any other extensions supported by the client. * In rare circumstances, where the server cannot process the request without the extension, the server MAY send a 421 (Extension Required) response. 8.2.5 Processing the Request ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ * Assuming all of the checks in the previous subsections are passed, the UAS processing becomes method-specific. * Section 10 covers the REGISTER request, Section 11 covers the OPTIONS request, Section 13 covers the INVITE request, and Section 15 covers the BYE request. 8.2.6 Generating the Response ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 8.2.6.1 Sending a Provisional Response """""""""""""""""""""""""""""""""""""" * When a 100 (Trying) response is generated, any Timestamp header field present in the request MUST be copied into this 100 (Trying) response. 8.2.6.2 Headers and Tags """""""""""""""""""""""" The header fields response MUST equal the header fields of the request:: From To Call-ID CSeq Via 8.2.7 Stateless UAS Behavior ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ * A stateless UAS is a UAS that does not maintain transaction state. * A UAS cannot be stateless unless the request processing for that method would always result in the same response if the requests are identical. * This rules out stateless registrars, for example. Stateless UASs do not use a transaction layer; they receive requests directly from the transport layer and send responses directly to the transport layer. * The stateless UAS role is needed primarily to handle unauthenticated requests for which a challenge response is issued. * If unauthenticated requests were handled statefully, then malicious floods of unauthenticated requests could create massive amounts of transaction state that might slow or completely halt call processing in a UAS, effectively creating a denial of service condition; for more information see Section 26.1.5. The most important behaviors of a stateless UAS are the following: - A stateless UAS MUST NOT send provisional (1xx) responses. - A stateless UAS MUST NOT retransmit responses. - A stateless UAS MUST ignore ACK requests. - A stateless UAS MUST ignore CANCEL requests. - To header tags MUST be generated for responses in a stateless manner - in a manner that will generate the same tag for the same request consistently. 8.3 Redirect Servers -------------------- * In some architectures it may be desirable to reduce the processing load on proxy servers that are responsible for routing requests, and improve signaling path robustness, by relying on redirection. 9 Canceling a Request ===================== * The previous section has discussed general UA behavior for generating requests and processing responses for requests of all methods. In this section, we discuss a general purpose method, called CANCEL. * The CANCEL request, as the name implies, is used to cancel a previous request sent by a client. Specifically, it asks the UAS to cease processing the request and to generate an error response to that request. CANCEL has no effect on a request to which a UAS has already given a final response. Because of this, it is most useful to CANCEL requests to which it can take a server long time to respond. For this reason, CANCEL is best for INVITE requests, which can take a long time to generate a response. In that usage, a UAS that receives a CANCEL request for an INVITE, but has not yet sent a final response, would "stop ringing", and then respond to the INVITE with a specific error response (a 487). 9.1 Client Behavior ------------------- * A CANCEL request SHOULD NOT be sent to cancel a request other than INVITE. 9.2 Server Behavior ------------------- * The processing of a CANCEL request at a server depends on the type of server. * A stateless proxy will forward it, a stateful proxy might respond to it and generate some CANCEL requests of its own, and a UAS will respond to it. 10 Registrations ================ 10.1 Overview ------------- * SIP offers a discovery capability. * If a user wants to initiate a session with another user, SIP must discover the current host(s) at which the destination user is reachable. * This discovery process is frequently accomplished by SIP network elements such as proxy servers and redirect servers which are responsible for receiving a request, determining where to send it based on knowledge of the location of the user, and then sending it there. * To do this, SIP network elements consult an abstract service known as a location service, which provides address bindings for a particular domain. * These address bindings map an incoming SIP or SIPS URI, sip:bob@biloxi.com, for example, to one or more URIs that are somehow "closer" to the desired user, sip:bob@engineering.biloxi.com, for example. 10.2 Constructing the REGISTER Request -------------------------------------- Figure 2: REGISTER example:: bob +----+ | UA | | | +----+ | |3)INVITE | carol@chicago.com chicago.com +--------+ V +---------+ 2)Store|Location|4)Query +-----+ |Registrar|=======>| Service|<=======|Proxy|sip.chicago.com +---------+ +--------+=======>+-----+ A 5)Resp | | | 1)REGISTER| | | | +----+ | | UA |<-------------------------------+ cube2214a| | 6)INVITE +----+ carol@cube2214a.chicago.com carol UAs can use three ways to determine the address to which to send registrations:: 1. by configuration, 2. using the address-of-record, 3. multicast. 10.3 Processing REGISTER Requests --------------------------------- * A registrar is a UAS that responds to REGISTER requests and maintains a list of bindings that are accessible to proxy servers and redirect servers within its administrative domain. 11 Querying for Capabilities ============================ * The SIP method OPTIONS allows a UA to query another UA or a proxy server as to its capabilities. Example OPTIONS request:: OPTIONS sip:carol@chicago.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877 Max-Forwards: 70 To: From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 63104 OPTIONS Contact: Accept: application/sdp Content-Length: 0 Example OPTIONS response:: SIP/2.0 200 OK Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877 ;received=192.0.2.4 To: ;tag=93810874 From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 63104 OPTIONS Contact: Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE Accept: application/sdp Accept-Encoding: gzip Accept-Language: en Supported: foo Content-Type: application/sdp Content-Length: 274 (SDP not shown) 12 Dialogs ========== * A key concept for a user agent is that of a dialog. * A dialog represents a peer-to-peer SIP relationship between two user agents that persists for some time. The dialog facilitates sequencing of messages between the user agents and proper routing of requests between both of them. The dialog represents a context in which to interpret SIP messages. * A dialog contains certain pieces of state needed for further message transmissions within the dialog. This state consists of the dialog ID, a local sequence number (used to order requests from the UA to its peer), a remote sequence number (used to order requests from its peer to the UA), a local URI, a remote URI, remote target, a boolean flag called "secure", and a route set, which is an ordered list of URIs. 12.1 Creation of a Dialog ------------------------- * Only 2xx and 101-199 responses with a To tag, where the request was INVITE, will establish a dialog. * A dialog established by a non-final response to a request is in the "early" state and it is called an early dialog. 12.2 Requests within a Dialog ----------------------------- * Once a dialog has been established between two UAs, either of them MAY initiate new transactions as needed within the dialog. * The UA sending the request will take the UAC role for the transaction. * The UA receiving the request will take the UAS role. * Note that these may be different roles than the UAs held during the transaction that established the dialog. 12.3 Termination of a Dialog ---------------------------- * In this specification, the BYE method terminates a session and the dialog associated with it. 13 Initiating a Session ======================= 13.1 Overview ------------- * When a user agent client desires to initiate a session (for example, audio, video, or a game), it formulates an INVITE request. * The INVITE request asks a server to establish a session. 13.2 UAC Processing ------------------- 13.2.1 Creating the Initial INVITE ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ * Since the initial INVITE represents a request outside of a dialog, Additional processing is required for the specific case of INVITE. 13.2.2 Processing INVITE Responses ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ * Once the INVITE has been passed to the INVITE client transaction, the UAC waits for responses for the INVITE. 13.3 UAS Processing ------------------- 13.3.1 Processing of the INVITE ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ * The UAS core will receive INVITE requests from the transaction layer. * Processing from here forward assumes that the INVITE is outside of a dialog, and is thus for the purposes of establishing a new session. 14 Modifying an Existing Session ================================ * A successful INVITE request (see Section 13) establishes both a dialog between two user agents and a session using the offer-answer model. * This section describes how to modify the actual session. This modification can involve changing addresses or ports, adding a media stream, deleting a media stream, and so on. This is accomplished by sending a new INVITE request within the same dialog that established the session. An INVITE request sent within an existing dialog is known as a ``re-INVITE``. * Either the caller or callee can modify an existing session. 14.1 UAC Behavior ----------------- * As a result, a UAC that wants to add a media stream, for example, will create a new offer that contains this media stream, and send that in an INVITE request to its peer. It is important to note that the full description of the session, not just the change, is sent. 14.2 UAS Behavior ----------------- * Section 13.3.1 describes the procedure for distinguishing incoming re-INVITEs from incoming initial INVITEs and handling a re-INVITE for an existing dialog. 15 Terminating a Session ======================== * The state of the session and the state of the dialog are very closely related. * When a session is initiated with an INVITE, each 1xx or 2xx response from a distinct UAS creates a dialog, and if that response completes the offer/answer exchange, it also creates a session. * As a result, each session is "associated" with a single dialog - the one which resulted in its creation. 15.1 Terminating a Session with a BYE Request --------------------------------------------- 15.1.1 UAC Behavior ^^^^^^^^^^^^^^^^^^^ * Once the BYE is constructed, the UAC core creates a new non-INVITE client transaction, and passes it the BYE request. The UAC MUST consider the session terminated (and therefore stop sending or listening for media) as soon as the BYE request is passed to the client transaction. * If the response for the BYE is a 481 (Call/Transaction Does Not Exist) or a 408 (Request Timeout) or no response at all is received for the BYE (that is, a timeout is returned by the client transaction), the UAC MUST consider the session and the dialog terminated. 15.1.2 UAS Behavior ^^^^^^^^^^^^^^^^^^^ * If the BYE does not match an existing dialog, the UAS core SHOULD generate a 481 (Call/Transaction Does Not Exist) response and pass that to the server transaction. * A UAS core receiving a BYE request for an existing dialog, Once done, the UAS SHOULD terminate the session (and therefore stop sending and listening for media). 16 Proxy Behavior ================= 16.1 Overview ------------- * SIP proxies are elements that route SIP requests to user agent servers and SIP responses to user agent clients. * A proxy can operate in either a stateful or stateless mode for each new request. When stateless, a proxy acts as a simple forwarding element. A stateful proxy remembers information (specifically, transaction state) about each incoming request and any requests it sends as a result of processing the incoming request. 16.2 Stateful Proxy ------------------- * When stateful, a proxy is purely a SIP transaction processing engine. For all new requests, including any with unknown methods, an element intending to proxy the request MUST:: 1. Validate the request (Section 16.3) 2. Preprocess routing information (Section 16.4) 3. Determine target(s) for the request (Section 16.5) 4. Forward the request to each target (Section 16.6) 5. Process all responses (Section 16.7) 16.3 Request Validation ----------------------- A valid message must pass the following checks:: 1. Reasonable Syntax 2. URI scheme 3. Max-Forwards 4. (Optional) Loop Detection 5. Proxy-Require 6. Proxy-Authorization 16.4 Route Information Preprocessing ------------------------------------ * This will only happen when the element sending the request to the proxy (which may have been an endpoint) is a strict router. 16.5 Determining Request Targets -------------------------------- Next, the proxy calculates the target(s) of the request. The set of targets will either be predetermined by the contents of the request or will be obtained from an abstract location service. 16.6 Request Forwarding ----------------------- For each target, the proxy forwards the request following these steps:: 1. Make a copy of the received request 2. Update the Request-URI 3. Update the Max-Forwards header field 4. Optionally add a Record-route header field value 5. Optionally add additional header fields 6. Postprocess routing information 7. Determine the next-hop address, port, and transport 8. Add a Via header field value 9. Add a Content-Length header field if necessary 10. Forward the new request 11. Set timer C 16.7 Response Processing ------------------------ As client transactions pass responses to the proxy layer, the following processing MUST take place:: 1. Find the appropriate response context 2. Update timer C for provisional responses 3. Remove the topmost Via 4. Add the response to the response context 5. Check to see if this response should be forwarded immediately 6. When necessary, choose the best final response from the response context The following processing MUST be performed on each response that is forwarded:: 7. Aggregate authorization header field values if necessary 8. Optionally rewrite Record-Route header field values 9. Forward the response 10. Generate any necessary CANCEL requests 16.8 Processing Timer C ----------------------- If timer C should fire, the proxy MUST either reset the timer with any value it chooses, or terminate the client transaction. 16.9 Handling Transport Errors ------------------------------ * If the transport layer notifies a proxy of an error when it tries to forward a request (see Section 18.4), the proxy MUST behave as if the forwarded request received a 503 (Service Unavailable) response. * If the proxy is notified of an error when forwarding a response, it drops the response. 16.10 CANCEL Processing ----------------------- * A proxy MUST cancel any pending client transactions associated with a response context when it receives a matching CANCEL request. 16.11 Stateless Proxy --------------------- * When acting statelessly, a proxy is a simple message forwarder. 16.12 Summary of Proxy Route Processing --------------------------------------- the processing a proxy performs on a request containing a Route header field can be summarized in the following steps:: 1. The proxy will inspect the Request-URI. 2. The proxy will inspect the URI in the topmost Route header field value. 3. The proxy will forward the request to the resource indicated by the URI in the topmost Route header field value or in the Request-URI if no Route header field is present. 16.12.1 Examples ^^^^^^^^^^^^^^^^ 16.12.1.1 Basic SIP Trapezoid """"""""""""""""""""""""""""" * This scenario is the basic SIP trapezoid, U1 -> P1 -> P2 -> U2, with both proxies record-routing U1 sends msg to P1:: INVITE sip:callee@domain.com SIP/2.0 Contact: sip:caller@u1.example.com P1 is not responsible for domain.com, so it looks it up in DNS and sends it there. It also adds a Record-Route header field value:: INVITE sip:callee@domain.com SIP/2.0 Contact: sip:caller@u1.example.com Record-Route: P2 gets this. It is responsible for domain.com so it runs a location service and rewrites the Request-URI:: INVITE sip:callee@u2.domain.com SIP/2.0 Contact: sip:caller@u1.example.com Record-Route: Record-Route: The callee at u2.domain.com gets this and responds with a 200 OK:: SIP/2.0 200 OK Contact: sip:callee@u2.domain.com Record-Route: Record-Route: The callee at u2 also sets its dialog state's remote target URI to sip:caller@u1.example.com and its route set to:: (,) * This is forwarded by P2 to P1 to U1 as normal. Now, U1 sets its dialog state's remote target URI to sip:callee@u2.domain.com and its route set to:: (,) U1 constructs the following BYE request:: BYE sip:callee@u2.domain.com SIP/2.0 Route: , P1 notices that it is not responsible for the resource indicated in the Request-URI so it doesn't change it. It does see that it is the first value in the Route header field, so it removes that value, and forwards the request to P2:: BYE sip:callee@u2.domain.com SIP/2.0 Route: * P2 also notices it is not responsible for the resource indicated by the Request-URI (it is responsible for domain.com, not u2.domain.com), so it doesn't change it. * It does see itself in the first Route header field value, so it removes it and forwards the following to u2.domain.com based on a DNS lookup against the Request-URI:: BYE sip:callee@u2.domain.com SIP/2.0 16.12.1.2 Traversing a Strict-Routing Proxy """"""""""""""""""""""""""""""""""""""""""" * In this scenario, a dialog is established across four proxies, each of which adds Record-Route header field values. The third proxy implements the strict-routing procedures specified in RFC 2543 and many works in progress. :: U1->P1->P2->P3->P4->U2 The INVITE arriving at U2 contains:: INVITE sip:callee@u2.domain.com SIP/2.0 Contact: sip:caller@u1.example.com Record-Route: Record-Route: Record-Route: Record-Route: U2 responds to with a 200 OK. Later, U2 sends the following BYE request to P4 based on the first Route header field value:: BYE sip:caller@u1.example.com SIP/2.0 Route: Route: Route: Route: P4 Notice does not contain the ``lr`` parameter, so before sending, it reformats the request to be::: BYE sip:p3.middle.com SIP/2.0 Route: Route: Route: P3 is a strict router, so it forwards the following to P2:: BYE sip:p2.example.com;lr SIP/2.0 Route: Route: P2:: BYE sip:caller@u1.example.com SIP/2.0 Route: P1:: BYE sip:caller@u1.example.com SIP/2.0 * Since P1 is not responsible for u1.example.com and there is no Route header field, P1 will forward the request to u1.example.com based on the Request-URI. 16.12.1.3 Rewriting Record-Route Header Field Values """""""""""""""""""""""""""""""""""""""""""""""""""" * In this scenario, U1 and U2 are in different private namespaces and they enter a dialog through a proxy P1, which acts as a gateway between the namespaces. :: U1->P1->U2 U1 sends:: INVITE sip:callee@gateway.rightprivatespace.com SIP/2.0 Contact: P1 uses its location service and sends the following to U2:: INVITE sip:callee@rightprivatespace.com SIP/2.0 Contact: Record-Route: U2 sends this 200 (OK) back to P1:: SIP/2.0 200 OK Contact: Record-Route: P1 rewrites its Record-Route header parameter to provide a value that U1 will find useful, and sends the following to U1:: SIP/2.0 200 OK Contact: Record-Route: Later, U1 sends the following BYE request to P1:: BYE sip:callee@u2.rightprivatespace.com SIP/2.0 Route: which P1 forwards to U2 as:: BYE sip:callee@u2.rightprivatespace.com SIP/2.0 17 Transactions =============== * SIP is a transactional protocol: interactions between components take place in a series of independent message exchanges. * Specifically, a SIP transaction consists of a single request and any responses to that request, which include zero or more provisional responses and one or more final responses. * Transactions have a client side and a server side. The client side is known as a client transaction and the server side as a server transaction. Figure 4: Transaction relationships:: +---------+ +---------+ +---------+ +---------+ | +-+|Request |+-+ +-+|Request |+-+ +-+|Request |+-+ | | |C||------->||S| |C||------->||S| |C||------->||S| | | |l|| ||e| |l|| ||e| |l|| ||e| | | |i|| ||r| |i|| ||r| |i|| ||r| | | |e|| ||v| |e|| ||v| |e|| ||v| | | |n|| ||e| |n|| ||e| |n|| ||e| | | |t|| ||r| |t|| ||r| |t|| ||r| | | | || || | | || || | | || || | | | |T|| ||T| |T|| ||T| |T|| ||T| | | |r|| ||r| |r|| ||r| |r|| ||r| | | |a|| ||a| |a|| ||a| |a|| ||a| | | |n|| ||n| |n|| ||n| |n|| ||n| | | |s||Response||s| |s||Response||s| |s||Response||s| | | +-+|<-------|+-+ +-+|<-------|+-+ +-+|<-------|+-+ | +---------+ +---------+ +---------+ +---------+ UAC Outbound Inbound UAS Proxy Proxy 17.1 Client Transaction ----------------------- 17.1.1 INVITE Client Transaction ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The INVITE transaction consists of a three-way handshake:: 1. The client transaction sends an INVITE, 2. the server transaction sends responses, 3. the client transaction sends an ACK. Figure 5: INVITE client transaction:: |INVITE from TU Timer A fires |INVITE sent Reset A, V Timer B fires INVITE sent +-----------+ or Transport Err. +---------| |---------------+inform TU | | Calling | | +-------->| |-------------->| +-----------+ 2xx | | | 2xx to TU | | |1xx | 300-699 +---------------+ |1xx to TU | ACK sent | | | resp. to TU | 1xx V | | 1xx to TU -----------+ | | +---------| | | | | |Proceeding |-------------->| | +-------->| | 2xx | | +-----------+ 2xx to TU | | 300-699 | | | ACK sent, | | | resp. to TU| | | | | NOTE: | 300-699 V | | ACK sent +-----------+Transport Err. | transitions | +---------| |Inform TU | labeled with | | | Completed |-------------->| the event | +-------->| | | over the action | +-----------+ | to take | ^ | | | | | Timer D fires | +--------------+ | - | | | V | +-----------+ | | | | | Terminated|<--------------+ | | +-----------+ Example, consider the following request:: INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKkjshdyff To: Bob From: Alice ;tag=88sja8x Max-Forwards: 70 Call-ID: 987asjd97y7atg CSeq: 986759 INVITE The ACK request for a non-2xx final response to this request would look like this:: ACK sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKkjshdyff To: Bob ;tag=99sa0xk From: Alice ;tag=88sja8x Max-Forwards: 70 Call-ID: 987asjd97y7atg CSeq: 986759 ACK 17.1.2 Non-INVITE Client Transaction ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ * Non-INVITE transactions do not make use of ACK. They are simple request-response interactions. 17.1.3 Matching Responses to Client Transactions ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ * When the transport layer in the client receives a response, it has to determine which client transaction will handle the response, so that the processing of Sections 17.1.1 and 17.1.2 can take place. * The branch parameter in the top Via header field is used for this purpose. 17.1.4 Handling Transport Errors ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Figure 6: non-INVITE client transaction:: |Request from TU |send request Timer E V send request +-----------+ +---------| |-------------------+ | | Trying | Timer F | +-------->| | or Transport Err.| +-----------+ inform TU | 200-699 | | | resp. to TU | |1xx | +---------------+ |resp. to TU | | | | | Timer E V Timer F | | send req +-----------+ or Transport Err. | | +---------| | inform TU | | | |Proceeding |------------------>| | +-------->| |-----+ | | +-----------+ |1xx | | | ^ |resp to TU | | 200-699 | +--------+ | | resp. to TU | | | | | | V | | +-----------+ | | | | | | | Completed | | | | | | | +-----------+ | | ^ | | | | | Timer K | +--------------+ | - | | | V | NOTE: +-----------+ | | | | transitions | Terminated|<------------------+ labeled with | | the event +-----------+ over the action to take 17.2 Server Transaction ----------------------- The server transaction is responsible for the delivery of requests to the TU and the reliable transmission of responses. It accomplishes this through a state machine. Figure 7: INVITE server transaction:: |INVITE |pass INV to TU INVITE V send 100 if TU won't in 200ms send response+-----------+ +--------| |--------+101-199 from TU | | Proceeding| |send response +------->| |<-------+ | | Transport Err. | | Inform TU | |--------------->+ +-----------+ | 300-699 from TU | |2xx from TU | send response | |send response | | +------------------>+ | | INVITE V Timer G fires | send response+-----------+ send response | +--------| |--------+ | | | Completed | | | +------->| |<-------+ | +-----------+ | | | | ACK | | | - | +------------------>+ | Timer H fires | V or Transport Err.| +-----------+ Inform TU | | | | | Confirmed | | | | | +-----------+ | | | |Timer I fires | |- | | | V | +-----------+ | | | | | Terminated|<---------------+ | | +-----------+ 18 Transport ============ * The transport layer is responsible for the actual transmission of requests and responses over network transports. * This includes determination of the connection to use for a request or response in the case of connection-oriented transports * The transport layer is responsible for managing persistent connections for transport protocols like TCP and SCTP, or TLS over those, including ones opened to the transport layer. * This includes connections opened by the client or server transports, so that connections are shared between client and server transport functions. 19 Common Message Components ============================ * There are certain components of SIP messages that appear in various places within SIP messages (and sometimes, outside of them) that merit separate discussion. 19.1 SIP and SIPS Uniform Resource Indicators --------------------------------------------- * A SIP or SIPS URI identifies a communications resource. 19.1.1 SIP and SIPS URI Components ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Its general form, in the case of a SIP URI, is:: sip:user:password@host:port;uri-parameters?headers 示例:: sip:alice@atlanta.com;maddr=239.255.255.1;ttl=15 19.1.2 Character Escaping Requirements ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ * (1): The default port value is transport and scheme dependent. The default is 5060 for sip: using UDP, TCP, or SCTP. The default is 5061 for sip: using TLS over TCP and sips: over TCP. * (2): The default transport is scheme dependent. For sip:, it is UDP. For sips:, it is TCP. 19.1.3 Example SIP and SIPS URIs ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ :: sip:alice@atlanta.com sip:alice:secretword@atlanta.com;transport=tcp sips:alice@atlanta.com?subject=project%20x&priority=urgent sip:+1-212-555-1212:1234@gateway.com;user=phone sips:1212@gateway.com sip:alice@192.0.2.4 sip:atlanta.com;method=REGISTER?to=alice%40atlanta.com sip:alice;day=tuesday@atlanta.com 19.1.4 URI Comparison ^^^^^^^^^^^^^^^^^^^^^ SIP and SIPS URIs are compared for equality according to the following rules:: - A SIP and SIPS URI are never equivalent. - Comparison of the userinfo of SIP and SIPS URIs is case-sensitive. - The ordering of parameters and header fields is not significant in comparing SIP and SIPS URIs. - Characters other than those in the "reserved" set (see RFC 2396 [5]) are equivalent to their ""%" HEX HEX" encoding. - An IP address that is the result of a DNS lookup of a host name does not match that host name. - For two URIs to be equal, the user, password, host, and port components must match. The URIs within each of the following sets are equivalent:: sip:%61lice@atlanta.com;transport=TCP sip:alice@AtLanTa.CoM;Transport=tcp sip:carol@chicago.com sip:carol@chicago.com;newparam=5 sip:carol@chicago.com;security=on sip:biloxi.com;transport=tcp;method=REGISTER?to=sip:bob%40biloxi.com sip:biloxi.com;method=REGISTER;transport=tcp?to=sip:bob%40biloxi.com sip:alice@atlanta.com?subject=project%20x&priority=urgent sip:alice@atlanta.com?priority=urgent&subject=project%20x The URIs within each of the following sets are not equivalent:: SIP:ALICE@AtLanTa.CoM;Transport=udp (different usernames) sip:alice@AtLanTa.CoM;Transport=UDP sip:bob@biloxi.com (can resolve to different ports) sip:bob@biloxi.com:5060 sip:bob@biloxi.com (can resolve to different transports) sip:bob@biloxi.com;transport=udp sip:bob@biloxi.com (can resolve to different port and transports) sip:bob@biloxi.com:6000;transport=tcp sip:carol@chicago.com (different header component) sip:carol@chicago.com?Subject=next%20meeting sip:bob@phone21.boxesbybob.com (even though that's what sip:bob@192.0.2.4 phone21.boxesbybob.com resolves to) Note that equality is not transitive:: - sip:carol@chicago.com and sip:carol@chicago.com;security=on are equivalent - sip:carol@chicago.com and sip:carol@chicago.com;security=off are equivalent But - sip:carol@chicago.com;security=on and sip:carol@chicago.com;security=off are not equivalent 19.1.5 Forming Requests from a URI ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 19.1.6 Relating SIP URIs and tel URLs ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ * When a tel URL (RFC 2806 [9]) is converted to a SIP or SIPS URI, the entire telephone-subscriber portion of the tel URL, including any parameters, is placed into the userinfo part of the SIP or SIPS URI. Thus, tel:+358-555-1234567;postd=pp22 becomes:: sip:+358-555-1234567;postd=pp22@foo.com;user=phone or sips:+358-555-1234567;postd=pp22@foo.com;user=phone not sip:+358-555-1234567@foo.com;postd=pp22;user=phone or sips:+358-555-1234567@foo.com;postd=pp22;user=phone 19.2 Option Tags ---------------- * Option tags are unique identifiers used to designate new options (extensions) in SIP 19.3 Tags --------- * The "tag" parameter is used in the To and From header fields of SIP messages. 20 Header Fields ================ Values in this column are:: R: header field may only appear in requests; r: header field may only appear in responses; 2xx, 4xx, etc.: A numerical value or range indicates response codes with which the header field can be used; c: header field is copied from the request to the response. The "proxy" column describes the operations a proxy may perform on a header field:: a: A proxy can add or concatenate the header field if not present. m: A proxy can modify an existing header field value. d: A proxy can delete a header field value. r: A proxy must be able to read the header field, and thus this header field cannot be encrypted. The next six columns relate to the presence of a header field in a method:: c: Conditional; requirements on the header field depend on the context of the message. m: The header field is mandatory. m*: The header field SHOULD be sent, but clients/servers need to be prepared to receive messages without that header field. o: The header field is optional. t: The header field SHOULD be sent, but clients/servers need to be prepared to receive messages without that header field. *: The header field is required if the message body is not empty. See Sections 20.14, 20.15 and 7.4 for details. -: The header field is not applicable. Table 2: Summary of header fields:: Header field where proxy ACK BYE CAN INV OPT REG ___________________________________________________________ Accept R - o - o m* o Accept 2xx - - - o m* o Accept 415 - c - c c c Accept-Encoding R - o - o o o Accept-Encoding 2xx - - - o m* o Accept-Encoding 415 - c - c c c Accept-Language R - o - o o o Accept-Language 2xx - - - o m* o Accept-Language 415 - c - c c c Alert-Info R ar - - - o - - Alert-Info 180 ar - - - o - - Allow R - o - o o o Allow 2xx - o - m* m* o Allow r - o - o o o Allow 405 - m - m m m Authentication-Info 2xx - o - o o o Authorization R o o o o o o Call-ID c r m m m m m m Call-Info ar - - - o o o Contact R o - - m o o Contact 1xx - - - o - - Contact 2xx - - - m o o Contact 3xx d - o - o o o Contact 485 - o - o o o Content-Disposition o o - o o o Content-Encoding o o - o o o Content-Language o o - o o o Content-Length ar t t t t t t Content-Type * * - * * * CSeq c r m m m m m m Date a o o o o o o Error-Info 300-699 a - o o o o o Expires - - - o - o From c r m m m m m m In-Reply-To R - - - o - - Max-Forwards R amr m m m m m m Min-Expires 423 - - - - - m MIME-Version o o - o o o Organization ar - - - o o o Priority R ar - - - o - - Proxy-Authenticate 407 ar - m - m m m Proxy-Authenticate 401 ar - o o o o o Proxy-Authorization R dr o o - o o o Proxy-Require R ar - o - o o o Record-Route R ar o o o o o - Record-Route 2xx,18x mr - o o o o - Reply-To - - - o - - Require ar - c - c c c Retry-After 404,413,480,486 - o o o o o 500,503 - o o o o o 600,603 - o o o o o Route R adr c c c c c c Server r - o o o o o Subject R - - - o - - Supported R - o o m* o o Supported 2xx - o o m* m* o Timestamp o o o o o o To c(1) r m m m m m m Unsupported 420 - m - m m m User-Agent o o o o o o Via R amr m m m m m m Via rc dr m m m m m m Warning r - o o o o o WWW-Authenticate 401 ar - m - m m m WWW-Authenticate 407 ar - o - o o o 20.1 Accept ----------- :: Accept: application/sdp;level=1, application/x-private, text/html 20.2 Accept-Encoding -------------------- :: Accept-Encoding: gzip 20.3 Accept-Language -------------------- Accept-Language: da, en-gb;q=0.8, en;q=0.7 20.4 Alert-Info --------------- :: Alert-Info: 20.5 Allow ---------- :: Allow: INVITE, ACK, OPTIONS, CANCEL, BYE 20.6 Authentication-Info ------------------------ :: Authentication-Info: nextnonce="47364c23432d2e131a5fb210812c" 20.7 Authorization ------------------ :: Authorization: Digest username="Alice", realm="atlanta.com", nonce="84a4cc6f3082121f32b42a2187831a9e", response="7587245234b3434cc3412213e5f113a5432" 20.8 Call-ID ------------ :: Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@biloxi.com i:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@192.0.2.4 20.9 Call-Info -------------- :: Call-Info: ;purpose=icon, ;purpose=info 20.10 Contact ------------- :: Contact: "Mr. Watson" ;q=0.7; expires=3600, "Mr. Watson" ;q=0.1 m: ;expires=60 20.11 Content-Disposition ------------------------- :: Content-Disposition: session 20.12 Content-Encoding ---------------------- :: Content-Encoding: gzip e: tar 20.13 Content-Language ---------------------- :: Content-Language: fr 20.14 Content-Length -------------------- :: Content-Length: 349 l: 173 20.15 Content-Type ------------------ :: Content-Type: application/sdp c: text/html; charset=ISO-8859-4 20.16 CSeq ---------- :: CSeq: 4711 INVITE 20.17 Date ---------- :: Date: Sat, 13 Nov 2010 23:29:00 GMT 20.18 Error-Info ---------------- :: SIP/2.0 404 The number you have dialed is not in service Error-Info: 20.19 Expires ------------- :: Expires: 5 20.20 From ---------- :: From: "A. G. Bell" ;tag=a48s From: sip:+12125551212@server.phone2net.com;tag=887s f: Anonymous ;tag=hyh8 20.21 In-Reply-To ----------------- :: In-Reply-To: 70710@saturn.bell-tel.com, 17320@saturn.bell-tel.com 20.22 Max-Forwards ------------------ :: Max-Forwards: 6 20.23 Min-Expires ----------------- :: Min-Expires: 60 20.24 MIME-Version ------------------ :: MIME-Version: 1.0 20.25 Organization ------------------ :: Organization: Boxes by Bob 20.26 Priority -------------- :: Subject: A tornado is heading our way! Priority: emergency or Subject: Weekend plans Priority: non-urgent 20.27 Proxy-Authenticate ------------------------ :: Proxy-Authenticate: Digest realm="atlanta.com", domain="sip:ss1.carrier.com", qop="auth", nonce="f84f1cec41e6cbe5aea9c8e88d359", opaque="", stale=FALSE, algorithm=MD5 20.28 Proxy-Authorization ------------------------- :: Proxy-Authorization: Digest username="Alice", realm="atlanta.com", nonce="c60f3082ee1212b402a21831ae", response="245f23415f11432b3434341c022" 20.29 Proxy-Require ------------------- :: Proxy-Require: foo 20.30 Record-Route ------------------ :: Record-Route: , 20.31 Reply-To -------------- :: Reply-To: Bob 20.32 Require ------------- :: Require: 100rel 20.33 Retry-After ----------------- :: Retry-After: 18000;duration=3600 Retry-After: 120 (I'm in a meeting) 20.34 Route ----------- :: Route: , 20.35 Server ------------ :: Server: HomeServer v2 20.36 Subject ------------- :: Subject: Need more boxes s: Tech Support 20.37 Supported --------------- :: Supported: 100rel 20.38 Timestamp --------------- :: Timestamp: 54 20.39 To -------- :: To: The Operator ;tag=287447 t: sip:+12125551212@server.phone2net.com 20.40 Unsupported ----------------- :: Unsupported: foo 20.41 User-Agent ---------------- :: User-Agent: Softphone Beta1.5 20.42 Via --------- :: Via: SIP / 2.0 / UDP first.example.com: 4000;ttl=16 ;maddr=224.2.0.1 ;branch=z9hG4bKa7c6a8dlze.1 20.43 Warning ------------- :: Warning: 307 isi.edu "Session parameter 'foo' not understood" Warning: 301 isi.edu "Incompatible network address type 'E.164'" 20.44 WWW-Authenticate ---------------------- :: WWW-Authenticate: Digest realm="atlanta.com", domain="sip:boxesbybob.com", qop="auth", nonce="f84f1cec41e6cbe5aea9c8e88d359", opaque="", stale=FALSE, algorithm=MD5 21 Response Codes ================= 21.1 Provisional 1xx -------------------- * Provisional responses, also known as informational responses, indicate that the server contacted is performing some further action and does not yet have a definitive response. :: 21.1.1 100 Trying 21.1.2 180 Ringing 21.1.3 181 Call Is Being Forwarded 21.1.4 182 Queued 21.1.5 183 Session Progress 21.2 Successful 2xx ------------------- * The request was successful. :: 21.2.1 200 OK 21.3 Redirection 3xx -------------------- * 3xx responses give information about the user's new location, or about alternative services that might be able to satisfy the call. :: 21.3.1 300 Multiple Choices 21.3.2 301 Moved Permanently 21.3.3 302 Moved Temporarily 21.3.4 305 Use Proxy 21.3.5 380 Alternative Service 21.4 Request Failure 4xx ------------------------ * 4xx responses are definite failure responses from a particular server. :: 21.4.1 400 Bad Request 21.4.2 401 Unauthorized 21.4.3 402 Payment Required 21.4.4 403 Forbidden 21.4.5 404 Not Found 21.4.6 405 Method Not Allowed 21.4.7 406 Not Acceptable 21.4.8 407 Proxy Authentication Required 21.4.9 408 Request Timeout 21.4.10 410 Gone 21.4.11 413 Request Entity Too Large 21.4.12 414 Request-URI Too Long 21.4.13 415 Unsupported Media Type 21.4.14 416 Unsupported URI Scheme 21.4.15 420 Bad Extension 21.4.16 421 Extension Required 21.4.17 423 Interval Too Brief 21.4.18 480 Temporarily Unavailable 21.4.19 481 Call/Transaction Does Not Exist 21.4.20 482 Loop Detected 21.4.21 483 Too Many Hops 21.4.22 484 Address Incomplete 21.4.23 485 Ambiguous 21.4.24 486 Busy Here 21.4.25 487 Request Terminated 21.4.26 488 Not Acceptable Here 21.4.27 491 Request Pending 21.4.28 493 Undecipherable 21.5 Server Failure 5xx ----------------------- * 5xx responses are failure responses given when a server itself has erred. :: 21.5.1 500 Server Internal Error 21.5.2 501 Not Implemented 21.5.3 502 Bad Gateway 21.5.4 503 Service Unavailable 21.5.5 504 Server Time-out 21.5.6 505 Version Not Supported 21.5.7 513 Message Too Large 21.6 Global Failures 6xx ------------------------ * 6xx responses indicate that a server has definitive information about a particular user, not just the particular instance indicated in the Request-URI. :: 21.6.1 600 Busy Everywhere 21.6.2 603 Decline 21.6.3 604 Does Not Exist Anywhere 21.6.4 606 Not Acceptable 22 Usage of HTTP Authentication =============================== * SIP provides a stateless, challenge-based mechanism for authentication that is based on authentication in HTTP. .. note:: Note that due to its weak security, the usage of "Basic" authentication has been deprecated(Use the "Digest" authentication mechanism). Servers MUST NOT accept credentials using the "Basic" authorization scheme, and servers also MUST NOT challenge with "Basic". This is a change from RFC 2543. 22.1 Framework -------------- realm string:: - Realm strings MUST be globally unique. It is RECOMMENDED that a realm string contain a hostname or domain name - Realm strings SHOULD present a human-readable identifier that can be rendered to a user. Example:: INVITE sip:bob@biloxi.com SIP/2.0 Authorization: Digest realm="biloxi.com", <...> 22.2 User-to-User Authentication -------------------------------- * When a UAS receives a request from a UAC, the UAS MAY authenticate the originator before the request is processed. The WWW-Authenticate response-header field MUST be included in 401 (Unauthorized) response messages:: WWW-Authenticate: Digest realm="biloxi.com", qop="auth,auth-int", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque="5ccc069c403ebaf9f0171e9517f40e41" * When the originating UAC receives the 401 (Unauthorized), it SHOULD re-originate the request with the proper credentials. An example of the Authorization header field is:: Authorization: Digest username="bob", realm="biloxi.com", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", uri="sip:bob@biloxi.com", qop=auth, nc=00000001, cnonce="0a4f113b", response="6629fae49393a05397450978507c4ef1", opaque="5ccc069c403ebaf9f0171e9517f40e41" 22.3 Proxy-to-User Authentication --------------------------------- * Similarly, when a UAC sends a request to a proxy server, the proxy server MAY authenticate the originator before the request is processed. 22.4 The Digest Authentication Scheme ------------------------------------- * The SIP scheme usage of Digest Authentication is almost completely identical to that for HTTP 23 S/MIME ========= * SIP messages carry MIME bodies and the MIME standard includes mechanisms for securing MIME contents to ensure both integrity and confidentiality (including the 'multipart/signed' and 'application/pkcs7-mime' MIME types 23.1 S/MIME Certificates ------------------------ * The certificates that are used to identify an end-user for the purposes of S/MIME differ from those used by servers in one important respect - rather than asserting that the identity of the holder corresponds to a particular hostname, these certificates assert that the holder is identified by an end-user address. 23.2 S/MIME Key Exchange ------------------------ * SIP itself can also be used as a means to distribute public keys in the following manner. 23.3 Securing MIME bodies ------------------------- The following is an example of an encrypted S/MIME SDP body within a SIP message(the text boxed in asterisks ("*") is encrypted):: INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 To: Bob From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Max-Forwards: 70 Contact: Content-Type: application/pkcs7-mime; smime-type=enveloped-data; name=smime.p7m Content-Disposition: attachment; filename=smime.p7m handling=required ******************************************************* * Content-Type: application/sdp * * * * v=0 * * o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com * * s=- * * t=0 0 * * c=IN IP4 pc33.atlanta.com * * m=audio 3456 RTP/AVP 0 1 3 99 * * a=rtpmap:0 PCMU/8000 * ******************************************************* 23.4 SIP Header Privacy and Integrity using S/MIME: Tunneling SIP ----------------------------------------------------------------- * As a means of providing some degree of end-to-end authentication, integrity or confidentiality for SIP header fields, S/MIME can encapsulate entire SIP messages within MIME bodies of type "message/sip" and then apply MIME security to these bodies in the same manner as typical SIP bodies. The following is an example of the use of a tunneled "message/sip" body:: INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 To: Bob From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Max-Forwards: 70 Date: Thu, 21 Feb 2002 13:02:03 GMT Contact: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary=boundary42 Content-Length: 568 --boundary42 Content-Type: message/sip INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 To: Bob From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Max-Forwards: 70 Date: Thu, 21 Feb 2002 13:02:03 GMT Contact: Content-Type: application/sdp Content-Length: 147 v=0 o=UserA 2890844526 2890844526 IN IP4 here.com s=Session SDP c=IN IP4 pc33.atlanta.com t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 --boundary42 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s; handling=required ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 7GhIGfHfYT64VQbnj756 --boundary42- 24 Examples =========== 24.1 Registration ----------------- Bob registers on start-up:: biloxi.com Bob's registrar softphone | | | REGISTER F1 | |<---------------| | 200 OK F2 | |--------------->| Figure 9: SIP Registration Example F1 REGISTER Bob -> Registrar:: REGISTER sip:registrar.biloxi.com SIP/2.0 Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7 Max-Forwards: 70 To: Bob From: Bob ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: Expires: 7200 Content-Length: 0 The registration expires after two hours. F2 200 OK Registrar -> Bob:: SIP/2.0 200 OK Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7 ;received=192.0.2.4 To: Bob ;tag=2493k59kd From: Bob ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: Expires: 7200 Content-Length: 0 24.2 Session Setup ------------------ This example contains the full details of the example session setup in Section 4. .. todo:: 具体看文档 25 Augmented BNF for the SIP Protocol ===================================== :: quoted-pair = "\" (%x00-09 / %x0B-0C / %x0E-7F) SIP-URI = "sip:" [ userinfo ] hostport uri-parameters [ headers ] SIPS-URI = "sips:" [ userinfo ] hostport uri-parameters [ headers ] userinfo = ( user / telephone-subscriber ) [ ":" password ] "@" user = 1*( unreserved / escaped / user-unreserved ) user-unreserved = "&" / "=" / "+" / "$" / "," / ";" / "?" / "/" password = *( unreserved / escaped / "&" / "=" / "+" / "$" / "," ) hostport = host [ ":" port ] host = hostname / IPv4address / IPv6reference hostname = *( domainlabel "." ) toplabel [ "." ] domainlabel = alphanum / alphanum *( alphanum / "-" ) alphanum toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT IPv6reference = "[" IPv6address "]" IPv6address = hexpart [ ":" IPv4address ] hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ] hexseq = hex4 *( ":" hex4) hex4 = 1*4HEXDIG port = 1*DIGIT The BNF for telephone-subscriber can be found in RFC 2806 [9]. Note, however, that any characters allowed there that are not allowed in the user part of the SIP URI MUST be escaped. uri-parameters = *( ";" uri-parameter) uri-parameter = transport-param / user-param / method-param / ttl-param / maddr-param / lr-param / other-param transport-param = "transport=" ( "udp" / "tcp" / "sctp" / "tls" / other-transport) other-transport = token user-param = "user=" ( "phone" / "ip" / other-user) other-user = token method-param = "method=" Method ttl-param = "ttl=" ttl maddr-param = "maddr=" host lr-param = "lr" other-param = pname [ "=" pvalue ] pname = 1*paramchar pvalue = 1*paramchar paramchar = param-unreserved / unreserved / escaped param-unreserved = "[" / "]" / "/" / ":" / "&" / "+" / "$" headers = "?" header *( "&" header ) header = hname "=" hvalue hname = 1*( hnv-unreserved / unreserved / escaped ) hvalue = *( hnv-unreserved / unreserved / escaped ) hnv-unreserved = "[" / "]" / "/" / "?" / ":" / "+" / "$" SIP-message = Request / Response Request = Request-Line *( message-header ) CRLF [ message-body ] Request-Line = Method SP Request-URI SP SIP-Version CRLF Request-URI = SIP-URI / SIPS-URI / absoluteURI absoluteURI = scheme ":" ( hier-part / opaque-part ) hier-part = ( net-path / abs-path ) [ "?" query ] net-path = "//" authority [ abs-path ] abs-path = "/" path-segments opaque-part = uric-no-slash *uric uric = reserved / unreserved / escaped uric-no-slash = unreserved / escaped / ";" / "?" / ":" / "@" / "&" / "=" / "+" / "$" / "," path-segments = segment *( "/" segment ) segment = *pchar *( ";" param ) param = *pchar pchar = unreserved / escaped / ":" / "@" / "&" / "=" / "+" / "$" / "," scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ) authority = srvr / reg-name srvr = [ [ userinfo "@" ] hostport ] reg-name = 1*( unreserved / escaped / "$" / "," / ";" / ":" / "@" / "&" / "=" / "+" ) query = *uric SIP-Version = "SIP" "/" 1*DIGIT "." 1*DIGIT message-header = (Accept / Accept-Encoding / Accept-Language / Alert-Info / Allow / Authentication-Info / Authorization / Call-ID / Call-Info / Contact / Content-Disposition / Content-Encoding / Content-Language / Content-Length / Content-Type / CSeq / Date / Error-Info / Expires / From / In-Reply-To / Max-Forwards / MIME-Version / Min-Expires / Organization / Priority / Proxy-Authenticate / Proxy-Authorization / Proxy-Require / Record-Route / Reply-To / Require / Retry-After / Route / Server / Subject / Supported / Timestamp / To / Unsupported / User-Agent / Via / Warning / WWW-Authenticate / extension-header) CRLF INVITEm = %x49.4E.56.49.54.45 ; INVITE in caps ACKm = %x41.43.4B ; ACK in caps OPTIONSm = %x4F.50.54.49.4F.4E.53 ; OPTIONS in caps BYEm = %x42.59.45 ; BYE in caps CANCELm = %x43.41.4E.43.45.4C ; CANCEL in caps REGISTERm = %x52.45.47.49.53.54.45.52 ; REGISTER in caps Method = INVITEm / ACKm / OPTIONSm / BYEm / CANCELm / REGISTERm / extension-method extension-method = token Response = Status-Line *( message-header ) CRLF [ message-body ] Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF Status-Code = Informational / Redirection / Success / Client-Error / Server-Error / Global-Failure / extension-code extension-code = 3DIGIT Reason-Phrase = *(reserved / unreserved / escaped / UTF8-NONASCII / UTF8-CONT / SP / HTAB) Informational = "100" ; Trying / "180" ; Ringing / "181" ; Call Is Being Forwarded / "182" ; Queued / "183" ; Session Progress Success = "200" ; OK Redirection = "300" ; Multiple Choices / "301" ; Moved Permanently / "302" ; Moved Temporarily / "305" ; Use Proxy / "380" ; Alternative Service Client-Error = "400" ; Bad Request / "401" ; Unauthorized / "402" ; Payment Required / "403" ; Forbidden / "404" ; Not Found / "405" ; Method Not Allowed / "406" ; Not Acceptable / "407" ; Proxy Authentication Required / "408" ; Request Timeout / "410" ; Gone / "413" ; Request Entity Too Large / "414" ; Request-URI Too Large / "415" ; Unsupported Media Type / "416" ; Unsupported URI Scheme / "420" ; Bad Extension / "421" ; Extension Required / "423" ; Interval Too Brief / "480" ; Temporarily not available / "481" ; Call Leg/Transaction Does Not Exist / "482" ; Loop Detected / "483" ; Too Many Hops / "484" ; Address Incomplete / "485" ; Ambiguous / "486" ; Busy Here / "487" ; Request Terminated / "488" ; Not Acceptable Here / "491" ; Request Pending / "493" ; Undecipherable Server-Error = "500" ; Internal Server Error / "501" ; Not Implemented / "502" ; Bad Gateway / "503" ; Service Unavailable / "504" ; Server Time-out / "505" ; SIP Version not supported / "513" ; Message Too Large Global-Failure = "600" ; Busy Everywhere / "603" ; Decline / "604" ; Does not exist anywhere / "606" ; Not Acceptable Accept = "Accept" HCOLON [ accept-range *(COMMA accept-range) ] accept-range = media-range *(SEMI accept-param) media-range = ( "*/*" / ( m-type SLASH "*" ) / ( m-type SLASH m-subtype ) ) *( SEMI m-parameter ) accept-param = ("q" EQUAL qvalue) / generic-param qvalue = ( "0" [ "." 0*3DIGIT ] ) / ( "1" [ "." 0*3("0") ] ) generic-param = token [ EQUAL gen-value ] gen-value = token / host / quoted-string Accept-Encoding = "Accept-Encoding" HCOLON [ encoding *(COMMA encoding) ] encoding = codings *(SEMI accept-param) codings = content-coding / "*" content-coding = token Accept-Language = "Accept-Language" HCOLON [ language *(COMMA language) ] language = language-range *(SEMI accept-param) language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) / "*" ) Alert-Info = "Alert-Info" HCOLON alert-param *(COMMA alert-param) alert-param = LAQUOT absoluteURI RAQUOT *( SEMI generic-param ) Allow = "Allow" HCOLON [Method *(COMMA Method)] Authorization = "Authorization" HCOLON credentials credentials = ("Digest" LWS digest-response) / other-response digest-response = dig-resp *(COMMA dig-resp) dig-resp = username / realm / nonce / digest-uri / dresponse / algorithm / cnonce / opaque / message-qop / nonce-count / auth-param username = "username" EQUAL username-value username-value = quoted-string digest-uri = "uri" EQUAL LDQUOT digest-uri-value RDQUOT digest-uri-value = rquest-uri ; Equal to request-uri as specified by HTTP/1.1 message-qop = "qop" EQUAL qop-value cnonce = "cnonce" EQUAL cnonce-value cnonce-value = nonce-value nonce-count = "nc" EQUAL nc-value nc-value = 8LHEX dresponse = "response" EQUAL request-digest request-digest = LDQUOT 32LHEX RDQUOT auth-param = auth-param-name EQUAL ( token / quoted-string ) auth-param-name = token other-response = auth-scheme LWS auth-param *(COMMA auth-param) auth-scheme = token Authentication-Info = "Authentication-Info" HCOLON ainfo *(COMMA ainfo) ainfo = nextnonce / message-qop / response-auth / cnonce / nonce-count nextnonce = "nextnonce" EQUAL nonce-value response-auth = "rspauth" EQUAL response-digest response-digest = LDQUOT *LHEX RDQUOT Call-ID = ( "Call-ID" / "i" ) HCOLON callid callid = word [ "@" word ] Call-Info = "Call-Info" HCOLON info *(COMMA info) info = LAQUOT absoluteURI RAQUOT *( SEMI info-param) info-param = ( "purpose" EQUAL ( "icon" / "info" / "card" / token ) ) / generic-param Contact = ("Contact" / "m" ) HCOLON ( STAR / (contact-param *(COMMA contact-param))) contact-param = (name-addr / addr-spec) *(SEMI contact-params) name-addr = [ display-name ] LAQUOT addr-spec RAQUOT addr-spec = SIP-URI / SIPS-URI / absoluteURI display-name = *(token LWS)/ quoted-string contact-params = c-p-q / c-p-expires / contact-extension c-p-q = "q" EQUAL qvalue c-p-expires = "expires" EQUAL delta-seconds contact-extension = generic-param delta-seconds = 1*DIGIT Content-Disposition = "Content-Disposition" HCOLON disp-type *( SEMI disp-param ) disp-type = "render" / "session" / "icon" / "alert" / disp-extension-token disp-param = handling-param / generic-param handling-param = "handling" EQUAL ( "optional" / "required" / other-handling ) other-handling = token disp-extension-token = token Content-Encoding = ( "Content-Encoding" / "e" ) HCOLON content-coding *(COMMA content-coding) Content-Language = "Content-Language" HCOLON language-tag *(COMMA language-tag) language-tag = primary-tag *( "-" subtag ) primary-tag = 1*8ALPHA subtag = 1*8ALPHA Content-Length = ( "Content-Length" / "l" ) HCOLON 1*DIGIT Content-Type = ( "Content-Type" / "c" ) HCOLON media-type media-type = m-type SLASH m-subtype *(SEMI m-parameter) m-type = discrete-type / composite-type discrete-type = "text" / "image" / "audio" / "video" / "application" / extension-token composite-type = "message" / "multipart" / extension-token extension-token = ietf-token / x-token ietf-token = token x-token = "x-" token m-subtype = extension-token / iana-token iana-token = token m-parameter = m-attribute EQUAL m-value m-attribute = token m-value = token / quoted-string CSeq = "CSeq" HCOLON 1*DIGIT LWS Method Date = "Date" HCOLON SIP-date SIP-date = rfc1123-date rfc1123-date = wkday "," SP date1 SP time SP "GMT" date1 = 2DIGIT SP month SP 4DIGIT ; day month year (e.g., 02 Jun 1982) time = 2DIGIT ":" 2DIGIT ":" 2DIGIT ; 00:00:00 - 23:59:59 wkday = "Mon" / "Tue" / "Wed" / "Thu" / "Fri" / "Sat" / "Sun" month = "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" / "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec" Error-Info = "Error-Info" HCOLON error-uri *(COMMA error-uri) error-uri = LAQUOT absoluteURI RAQUOT *( SEMI generic-param ) Expires = "Expires" HCOLON delta-seconds From = ( "From" / "f" ) HCOLON from-spec from-spec = ( name-addr / addr-spec ) *( SEMI from-param ) from-param = tag-param / generic-param tag-param = "tag" EQUAL token In-Reply-To = "In-Reply-To" HCOLON callid *(COMMA callid) Max-Forwards = "Max-Forwards" HCOLON 1*DIGIT MIME-Version = "MIME-Version" HCOLON 1*DIGIT "." 1*DIGIT Min-Expires = "Min-Expires" HCOLON delta-seconds Organization = "Organization" HCOLON [TEXT-UTF8-TRIM] Priority = "Priority" HCOLON priority-value priority-value = "emergency" / "urgent" / "normal" / "non-urgent" / other-priority other-priority = token Proxy-Authenticate = "Proxy-Authenticate" HCOLON challenge challenge = ("Digest" LWS digest-cln *(COMMA digest-cln)) / other-challenge other-challenge = auth-scheme LWS auth-param *(COMMA auth-param) digest-cln = realm / domain / nonce / opaque / stale / algorithm / qop-options / auth-param realm = "realm" EQUAL realm-value realm-value = quoted-string domain = "domain" EQUAL LDQUOT URI *( 1*SP URI ) RDQUOT URI = absoluteURI / abs-path nonce = "nonce" EQUAL nonce-value nonce-value = quoted-string opaque = "opaque" EQUAL quoted-string stale = "stale" EQUAL ( "true" / "false" ) algorithm = "algorithm" EQUAL ( "MD5" / "MD5-sess" / token ) qop-options = "qop" EQUAL LDQUOT qop-value *("," qop-value) RDQUOT qop-value = "auth" / "auth-int" / token Proxy-Authorization = "Proxy-Authorization" HCOLON credentials Proxy-Require = "Proxy-Require" HCOLON option-tag *(COMMA option-tag) option-tag = token Record-Route = "Record-Route" HCOLON rec-route *(COMMA rec-route) rec-route = name-addr *( SEMI rr-param ) rr-param = generic-param Reply-To = "Reply-To" HCOLON rplyto-spec rplyto-spec = ( name-addr / addr-spec ) *( SEMI rplyto-param ) rplyto-param = generic-param Require = "Require" HCOLON option-tag *(COMMA option-tag) Retry-After = "Retry-After" HCOLON delta-seconds [ comment ] *( SEMI retry-param ) retry-param = ("duration" EQUAL delta-seconds) / generic-param Route = "Route" HCOLON route-param *(COMMA route-param) route-param = name-addr *( SEMI rr-param ) Server = "Server" HCOLON server-val *(LWS server-val) server-val = product / comment product = token [SLASH product-version] product-version = token Subject = ( "Subject" / "s" ) HCOLON [TEXT-UTF8-TRIM] Supported = ( "Supported" / "k" ) HCOLON [option-tag *(COMMA option-tag)] Timestamp = "Timestamp" HCOLON 1*(DIGIT) [ "." *(DIGIT) ] [ LWS delay ] delay = *(DIGIT) [ "." *(DIGIT) ] To = ( "To" / "t" ) HCOLON ( name-addr / addr-spec ) *( SEMI to-param ) to-param = tag-param / generic-param Unsupported = "Unsupported" HCOLON option-tag *(COMMA option-tag) User-Agent = "User-Agent" HCOLON server-val *(LWS server-val) Via = ( "Via" / "v" ) HCOLON via-parm *(COMMA via-parm) via-parm = sent-protocol LWS sent-by *( SEMI via-params ) via-params = via-ttl / via-maddr / via-received / via-branch / via-extension via-ttl = "ttl" EQUAL ttl via-maddr = "maddr" EQUAL host via-received = "received" EQUAL (IPv4address / IPv6address) via-branch = "branch" EQUAL token via-extension = generic-param sent-protocol = protocol-name SLASH protocol-version SLASH transport protocol-name = "SIP" / token protocol-version = token transport = "UDP" / "TCP" / "TLS" / "SCTP" / other-transport sent-by = host [ COLON port ] ttl = 1*3DIGIT ; 0 to 255 Warning = "Warning" HCOLON warning-value *(COMMA warning-value) warning-value = warn-code SP warn-agent SP warn-text warn-code = 3DIGIT warn-agent = hostport / pseudonym ; the name or pseudonym of the server adding ; the Warning header, for use in debugging warn-text = quoted-string pseudonym = token WWW-Authenticate = "WWW-Authenticate" HCOLON challenge extension-header = header-name HCOLON header-value header-name = token header-value = *(TEXT-UTF8char / UTF8-CONT / LWS) message-body = *OCTET 26 Security Considerations: Threat Model and Security Usage Recommendations =========================================================================== * SIP is not an easy protocol to secure. Its use of intermediaries, its multi-faceted trust relationships, its expected usage between elements with no trust at all, and its user-to-user operation make security far from trivial. .. todo:: todo 27 IANA Considerations ====================== 28 Changes From RFC 2543 ======================== 28.1 Major Functional Changes ----------------------------- 28.2 Minor Functional Changes ----------------------------- A Table of Timer Values ======================= Table 4: Summary of timers:: Timer Value Section Meaning ---------------------------------------------------------------------- T1 500ms default Section 17.1.1.1 RTT Estimate T2 4s Section 17.1.2.2 The maximum retransmit interval for non-INVITE requests and INVITE responses T4 5s Section 17.1.2.2 Maximum duration a message will remain in the network Timer A initially T1 Section 17.1.1.2 INVITE request retransmit interval, for UDP only Timer B 64*T1 Section 17.1.1.2 INVITE transaction timeout timer Timer C > 3min Section 16.6 proxy INVITE transaction bullet 11 timeout Timer D > 32s for UDP Section 17.1.1.2 Wait time for response 0s for TCP/SCTP retransmits Timer E initially T1 Section 17.1.2.2 non-INVITE request retransmit interval, UDP only Timer F 64*T1 Section 17.1.2.2 non-INVITE transaction timeout timer Timer G initially T1 Section 17.2.1 INVITE response retransmit interval Timer H 64*T1 Section 17.2.1 Wait time for ACK receipt Timer I T4 for UDP Section 17.2.1 Wait time for 0s for TCP/SCTP ACK retransmits Timer J 64*T1 for UDP Section 17.2.2 Wait time for 0s for TCP/SCTP non-INVITE request retransmits Timer K T4 for UDP Section 17.1.2.2 Wait time for 0s for TCP/SCTP response retransmits